OAuth (Open Authorization) is an open standard for authorization. When certain applications (client applications) accesses users' (i.e. resource owner) protected resources (e.g., photos, videos, contact lists), which are owned by another application (i.e. resource server) a double authentication is required. The client application and the resource owner need to be authenticated by the resource server before allowing any access to the protected resources. The OAuth enables resource owners to provide specific and time bound rights to access the protected resources to the client applications without having to hand out their credentials, typically username and password. The OAuth is based on three-party trust federation: client application, resource server and resource owner.
The OAuth allows resource owners to grant rights to access their information to a third party client application, which the user cannot trust entirely. The information being accessed is typically stored with another resource server. This access grant is provided as a result of the client application initiating an authorization-flow. The authorization flow is initiated to an authorization-endpoint (also known as authorization server, a component of resource server that handles the authorization flow). Prior to the authorization-flow initiation the authorization server mandates the client application to register with itself. During the process of registration a client identifier (ID) is assigned to the client application. Upon completion of the authorization flow, the client applications are issued a time-bound access-token instead of the protected data being exposed to the full extent. Each access-token grants access to a specific site (e.g., a video editing site), to a specific resources (e.g., just videos from a specific album), and to specific time duration (e.g., the next 2 hours). Upon initiation of the authorization flow, the authorization end-point gets the control. Upon completion of authorization flow, the authorization end point returns the control back to the client application by means of the redirect-endpoint.
The OAuth is defined only for Hyper Text Transfer Protocol (HTTP) Transport. The authorization-endpoint, redirect-endpoint should be valid HTTP URIs. As the OAuth requires redirect endpoints to be the HTTP URIs, packaged web applications cannot get the control back from authorization page, as they do not have HTTP end point. And therefore, as they cannot get the control back from the authorization page, the packaged web applications cannot use the OAuth mechanism in the usual way.
For the packaged web applications to use the OAuth, they need support from a web runtime engine. The web runtime engine can capture the redirect end point and instead of redirecting the web page associated with the URI it would notify the packaged web application with the captured redirect end point. However, this mechanism opens up the possibility of session fixation type of attacks. A malicious packaged web application can use the credentials and redirect end points of another genuine application and dupe the resource owner. In other traditional methods, even if the authorization server uses a transport layer security during authorization flow, the client ID and the redirect URI can be seen from some other network sniffer tools and http referrer headers. Once the client ID and the redirect URI of another application is known, an attacker can package a new application using the credentials and misuse the access to the protected resource.
Thus, there is a need of robust method and system to add an additional of security mechanism for the packaged web applications to ensure that the redirect endpoint is not that of another application.
The above information is presented as background information only to help the reader to understand the present disclosure. Applicants have made no determination and make no assertion as to whether any of the above might be applicable as Prior Art with regard to the present application.